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REAL PARTY IN INTEREST 

The real party in interest is General Electric Capital Corporation, by way 
of assignment from Murren et al., who is the named inventive entity and is 
captioned in the present Brief. 
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RELATED APPEALS AND INTERFERENCES 

While not formally related (as defined under 35 U.S.C.§§120 or 121), a Notice 
of Appeal has been filed in co-pending Application Serial Number 09/845,752 
entitled; "Process for Managing the Presentation and Rendering of Application 
Content", naming inventive entity Murren et al. No other Appeals or 
Interferences are believed to be pending or relevant under M.P. E. P. §1205.02. 

Due to the rationales cited in some of the Examiner's 
"Objections/Requirements", the "Objections/Requirements" raise issues which 
are properly the subject of an Appeal to this Board. The 
"Objections/Requirements" were the subject of a Petition to the Commissioner 
under 37 CFR 1.181, which remains pending. The "Objections/Requirements" 
are discussed herein with respect to the matters of law which properly addressed 
in this Appeal. Applicant seeks reversal of the "Objections/Requirements" as the 
rationales cited by the Examiner are within the purview of this Board. Applicant 
appreciates the "unordinary" nature of including matters which are normally the 
subject of a petition in an Appeal. M.P.E.P. £1201. 
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STATUS OF CLAIMS 

Allowed Claims : No claims have been allowed. 
Cancelled Claims : No claims have been cancelled. 

Pending Claims : Claims 1-30, 48-51 and 58 are pending examination in the 
application and stand finally rejected by the Examiner. Claims 31-37 and 52-57 
are withdrawn. 

Appealed claims : Claims 1-30, 48-5 1 and 58 form the basis for this appeal. 
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STATUS OF AMENDMENTS 

No amendment to the claims has been made since the Final Action of 
August 9, 2006. 

On April 28, 2006 Applicant filed an amendment and response. The 
amendment (in addition to amending the Written Description) added new Claim 
58. 

On September 12, 2005 Applicant filed a Response and amended Claims 
1,16 and 48. 
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SUMMARY OF THE CLAIMED SUBJECT MATTER 

A multi-layer software architecture for construction of diverse domains, 
such as business domains, is discussed. The instant application describes 
hierarchical arranged architectures which may permit removal or modification 
of layers within the hierarchy without impacting other layers. Application, 
Abstract. 

Following is a brief summary of independent claims 1, 48 and 58 with 
exemplary references to the disclosure inserted for convenience. Dependent 
Claims 10, 17, 20 and 22 are included as the claims are specifically discussed. 
References should not be understood as limiting any feature to the recited 
portions of the disclosure. 

Claim 1 recites a server system (FIGS. 1 and 2) comprising: one or more 
computers; and a multi-layer application (FIG. 2, 110) executing on the computers 
(112(1), 112(2), 112(3), . . ., 112(s)) (page 6, line 24- page 7, line 27) to handle 
client requests submitted by various client devices (102), the multi-layer 
application (FIG. 2, 110) (pages 8, line 19- page 9, line 2) comprising: a problem- 
solving logic layer (204 (for a business logic) (page 9, lines 11-21) to process the 
client (102) requests according to an associated problem domain (page 11, lines 1- 
4), wherein the problem domain pertains to a particular category of service, the 
problem-solving logic layer (204) (page 9, lines 11-21) containing one or more 
execution models (230) to perform various sets of tasks when processing the client 
requests, the problem-solving logic layer (204) producing replies to the client 
requests; an execution environment layer (202) (page 9, lines 22-27) to receive the 
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client requests and select an appropriate execution model (230) in the problem- 
solving logic layer (204) for processing the client requests; an interfacing layer 
[which may include 208, 206 (which are specifically recited in Claim 10)] to 
interface the problem-solving logic layer (204) with one or more resources 
(108(1), 108(2), . . ., 108(M)) so that the execution models (230) may utilize the 
resources (108(1), 108(2), . . 108(M)) when processing the client requests; and a 
presentation layer (212) to receive the replies produced by the problem-solving 
logic layer (204) and to structure the replies in a manner that makes the replies 
presentable on the various client devices, wherein any of the layers may be 
changed without impacting other layers (page 6, lines 10-21). 

Claim 10 recites a server system (FIG. 1, 112(1), 112(2), 112(3), . . ., 
1 12(S)) as recited in claim 1, wherein the interfacing layer comprises: a data 
abstraction layer (208) (page 12, lines 9-20) to obtain data from the resources and 
map the data into a domain framework (250) that models information flow for a 
specific problem domain; and a data coordination layer (206) (page 12, lines 9-20) 
that provides an interface for the problem-solving logic layer (204), in this case a 
business logic layer) to access the domain framework of the data abstraction layer 
and obtain the data. 

Claim 17 recites a server system as recited in claim 1, wherein the 
presentation layer (212) (page 15, lines 8-17) comprises: 

a presentation module to determine how the replies will appear on the client 
devices to users; and 
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a rendering module (260), separate from the presentation module(page 15, 
lines 1-17), to determine how to render the replies on the client devices. 

Claim 20 recites a server system (FIG. 1, 1 12(1), 1 12(2), 1 12(3), . . ., 
1 12(S)) as recited in claim 1, further comprising a constraint system to constrain 
operation of the multi-layer application (FIG. 2) (page 12, lines 9-20) according to 
multiple different constraints (page 50, line 17-page 55, line 25), the constraint 
system comprising a hierarchy (FIG 12) of constraint layers (1202(l)-1202(k)), 
with each constraint layer containing a set of one or more constraints that 
customize operation of the multi-layer application. 

Claim 22 recites server system as recited in claim 21, wherein the hierarchy 
of constraints comprises constraints selected from a group of constraints (FIG. 12) 
comprising: legally mandated constraints (page 51, lines 11-17 and page 52, line 
26-page 53, line 4) to constrain operation of the multi-layer application according 
to legal principles; company-mandated constraints(page 53, lines 5-1 1) to 
constrain operation of the multi-layer application according to preferences of a 
company that operates the application; customer constraints (page 53, lines 12-19) 
to constrain operation of the multi-layer application according to preferences of 
customers; cultural constraints (page 53, lines 12-19) to constrain operation of the 
multi-layer application according to cultural aspects; and end user constraints to 
constrain operation of the multi-layer application according to preferences of an 
enduser(page 53, lines 20-24). 
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Claim 29 recites a server system as recited in claim 1, further comprising: 
a resource bundle (page 94, lines 20-30)containing locale-specific content 
that is authored for a particular locale; and 

a resource bundle manager (2202) (page 98, lines 16-22) to populate a 
locale-independent core (FIG. 23) with the locale-sensitive content in the resource 
bundle to produce a computer-servable document that can be served by the multi- 
layer application to the particular locale. 

Claim 30 recites a server system as recited in claim 29, wherein the 
resource bundle manager (2202) (page 98, lines 16-22) resides in the interfacing 
layer (FIG. 2 and 22). 

Claim 48 recites a method (FIG. 3) for processing client requests in a 
system (FIG. 1), comprising: receiving requests from multiple clients (302), the 
requests being related to a business-related problem domain (page 6, lines 1-5), 
wherein the business-related problem domain pertains to a particular category of 
business-related service (page 3, lines 14-17 and page 6, lines 7-10); processing 
(308) the requests within problem- solving logic (204) to produce replies within the 
business-related problem domain(page 12, lines 1-5), the processing comprising 
requesting data to be used in formulating the replies (page 17, lines 16-22); 
retrieving the data from one or more external resources (page 17, lines 23-27) and 
mapping the data to a domain framework for the business-related problem domain 
(page 3, lines 25-26; page 12, lines 22-25), the domain framework being 
independent from the problem-solving logic (page 9, line 18); and interfacing 
(page 3, line 27- page 4, linel) the problem-solving logic to the domain 



framework to obtain the data for use in processing the request, wherein a new 
business-related problem domain can be exchanged for a previous business-related 
problem domain by replacing one or more components of the system, without 
having to reconstruct an entire application solution for the new business-related 
problem domain. 

Claim 58 recites a server system (FIG. 1, 112(1), 112(2), 112(3), . . ., 
112(S))comprising: one or more computers (112(1), 112(2), 112(3), . . ., 112(S)) ; 
and a multi-layer application (FIG. 2, 110) executing on the computers to handle 
client requests submitted by various client devices (302), the multi-layer 
application comprising: a problem-solving logic layer (an exemplary business 
layer is discussed, 204) to process the client requests according to an associated 
problem domain(page 6, lines 5-10), wherein the problem domain pertains to a 
particular category of service (page 3, lines 14-17 and page 6, lines 7-10), the 
problem-solving logic layer containing one or more execution models (230) to 
perform various sets of tasks when processing the client requests, the problem- 
solving logic layer (204) producing replies to the client requests (302); an 
execution environment layer(202) to receive the client requests and select an 
appropriate execution model (230) in the problem-solving logic layer (204) for 
processing the client requests; an interfacing layer (below) to interface the 
problem-solving logic layer with one or more resources (108(1), 108(2), . . ., 
108(M)) so that the execution models (230) may utilize the resources when 
processing the client requests, wherein the interfacing layer comprises: a data 
abstraction layer (208) to obtain data from the resources and map the data into a 
domain framework (250) that models information flow for a specific problem 
domain; and a data coordination layer (206) that provides an interface for the 
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problem-solving logic layer to access the domain framework (250) of the data 
abstraction layer and obtain the data; and a presentation layer (212) to receive the 
replies produced by the problem-solving logic layer and to structure the replies in 
a manner that makes the replies presentable on the various client devices(page 10, 
lines 3-5). 



10 



GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1. The Specification and Claims 1-30 and 48-51 stand rejected 
under 35 U.S.C. §112, paragraph one. A decision on this matter would 
obviate a Requirement for a Substitute Specification, under 37 CFR 
1.125. 

2. Claims 1-30 and 48-51 stand rejected under 35 U.S.C. §112, 
paragraph two. 

3. The Drawings are "objected" to under 37 CFR 1.81(a). As 
this "Objection" cites "37 CFR 1.81(a)" mandating drawings where 
"necessary") this "Objection" touches of the merits of this Application 
under 35 U.S.C. §113 first sentence, rather than 35 U.S.C. §113, second 
sentence (where drawings are merely acknowledged). Applicant appeals 
on this basis. 

4. Claims 1-9, 12-16, 18-21, 23-24 and 48-51 stand rejected 35 
U.S.C. § 102(b) over Stevens, W, Unix® Network Programming, PTR 
Prentice Hall, Englewood Cliffs, NJ, selected portions (1990). 
(Hereinafter, "Stevens") 

5. Claims 10, 11, 17, 22, 25-30 and 58 stand rejected under 35 
U.S.C. § 103(a) over the following combinations. 

a) Claim 17 is rejected over Stevens in view of Official 

Notice. 

b) Claim 22 is rejected over Stevens (alone). 



c) Claims 10, 11 and 58 are rejected over Stevens in view of 
Gilly, D., Unix® in a Nutshell; A Desktop Quick Reference for System V 
Release 4 and Solaris 2.0, O'Reilly & Associates, Inc., Cambridge, 
selected passages (1986). (Hereinafter "Gilly"). 

d) Claims 25-28 are rejected over Stevens in view of Peek, et 
al., Unix Power Tools®, O'Reilly & Associates, Inc., Cambridge, selected 
passages (1997). (Hereinafter "Peek"). 

e) Claims 29 and 30 are rejected over Stevens in view of 
Tuthill, et al., Creating Worldwide Software: Solaris International 
Developer's Guide 2 nd Edition, Sun Microsystems Press, Mountain View, 
CA, selected portions (1997). 

6. Claims 1,17, 20-25 and 48-50 are provisionally rejected over 
a non-statutory double patenting rejection. Applicant appeals the 
implication (although provisionally rejected) of the aforementioned 
claims. In particular, the Examiner has issued the provisional rejection on 
the following rationales: 

a) Claims 1,17, 48-50 are provisionally rejected over "claims 
1-8 of co-pending Application No. 09/845,752 Final Action Dated 8/9/06, 
page 18-22, item 78-85. (While the Examiner asserts that "09/847,067" is 
utilized, this statement is incorrect as the claim language in the 
09/847,067 Application does not match that cited in the Final Action). 
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b) Claims 20-22 are provisionally rejected over "claims 1-8 of 
co-pending Application No. 09/845,780 in view of 09/845,752." Final 
Action Dated 8/9/06, page 22, item 93. 

c) Claims 23 and 24 are provisionally rejected over "claim 1 
of co-pending Application No. 0/847,037 (sic 09/847,037) in view of 
09/845,752." Final Action Dated 8/9/06, page 21, item 86. 

d) Claim 25 is provisionally rejected over "claim 1 of co- 
pending Application No. 09/845,752 in view of 09/847,037 and 
09/847,038 and 09/845,751." Final Action Dated 8/9/06, page 21, item 
90. 
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ARGUMENT 



Brief History: 

Due to the examination in this case, Applicant includes a brief historical 
summary for the Board's convenience. This is in accordance with M.P.E.P. 
£1205.02. 

The instant application was filed on April 30, 2001 with Claims 1-57 of which 
Claims 1, 31, 43, 48, and 52 are independent. In chronological order: 

1) In response to a Restriction Requirement of December 21, 2004, Applicant 
elected to prosecute Claims 1-30 and 48-51, included in Group I, and traversed the 
restriction requirement, arguing that examination of all the included claims would 
not result in an undue burden on the Office. 

2) A non-final Action was mailed on March 10, 2005 the Action included 
rejections directed to the following aspects: 

a. The Drawings were objected under 3 7 CFR 1.81(a); 

b. The Specification was rejected under 35 U.S.C. §112, paragraph one 

c. Claims 1-30 and 48-51 were provisionally rejected over the 
judicially created doctrine obviousness double patenting rejection over several 
other applications filed on the behalf of the assignee of the present application. 
(Applicant in a paper dated September 12, 2005 noted three applications were 
outside of the "family" of cases cited by the Examiner); 

d. An information request under 37 CFR 1.105 sought documentation 
related to the following: a documentation of actual uses; an identification of 
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products and services embodying the claimed subject matter; an identification of 
the properties of similar products and services found in the prior art; citation and 
copies of each publication that any of the applicants relied on to draft the claimed 
subject matter, including a sub-request for a concise explanation; the names of 
products and services that have incorporated the claimed subject matter prior to 
filing; 

e. Claims 1-30 and 48-51 were rejected under 35 U.S.C. §112, 
paragraph two; 

f. Claims 1-9, 12-16, 18-21, 23-24, and 48-51 were rejected under 35 
U.S.C. § 102(b) over a non-patent reference entitled: "Unix Network 
Programming" (Stevens); and 

g. The below Claims were rejected under 35 U.S.C. §103 (a): 
Claim 17 was rejected over Stevens in-view of "Official Notice"; 
Claims 10 and 11 were rejected over Stevens in-view of Gilly; 
Claims 25-28 were rejected over Stevens in-view of Peek; and 
Claims 29 and 30 were rejected over Stevens reference in-view of 

Tuthill. 

3) On September 12, 2005 Applicant filed an IDS citing both patent and non- 
patent documents. 

4) Concurrently with Item 3, the Applicant filed a response and amended 
Claims 1, 16 and 48. Applicant also noted that within the one year grace period 
afforded by 35 U.S.C. 102(b) "GEtheSource" incorporated logic generally related 
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to claimed subject matter. The response included arguments directed to the 
rejections noted in Item 2. 

5) On November 30, 2005 the Office issued a non-final Action including a 
"Response to Argument" section which generally maintained the 
rejection/objection listed in Item 3 and included the following obviousness double 
patenting objections: Claims 1, 17 and 48-50 Applications 09/847,067; Claims 
23 and 24 Application 0/847,037 (presumed to be 09/847,037) "in-view of 
Application 09/845,752; Claim 25 Application 09/845,752 "in view of 
Application 09/847,037 and Application 09/847,038 and Application 09/845,751; 
Claims 20-22 Application 09/845,780 "in view of Application 09/845,752. The 
Action also imposed a "Requirement for Information" and requested 
documentation of the development and deployment of "GEtheSource." 

6) On April 28, 2006 Applicant filed an IDS citing both patent and non-patent 
documents. 

7) On April 28, 2006 Applicant filed an amendment and response. The 
amendment amended a paragraph on Page 13, commencing on line 19 and added 
new Claim 58. The response addressed the issues raised in the November 30, 
2005 Action (Item 5). 
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8) On June 14, 2006 counsel for the Applicant and the Examiner conducted an 
interview. No agreement was reached. 



9) The instant Final Rejection issued on August 9, 2006. 

10) Applicant filed a Response on 2/9/07. The Response requested 
reconsideration of the pending Rejections, Objections and Requirements, in light 
of the Applicant's arguments. 

11) Per Examiner's request, an Interview was held on March 1, 2007. No 
agreement was reached. 

12) Applicant filed an appeal on 2/9/07. 

13) On 5/4/07 Applicant filed a Petition requesting relief from various 
Examiner Objections/Requirements. 

FIRST GROUND OF REJECTION: The Specification and Claims 1-30 and 48- 
51 satisfy the requirements of 35 U.S.C. § 1 12, first paragraph (enablement). 

This issue is also "intertwined" with a pending Petition to the 
Commissioner inasmuch as, the Examiner has incorrectly asserted non- enablement 
under 35 U.S.C. §1 12, paragraph one as a basis for a Requirement for a Substitute 
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Specification under 37 CFR 1.125(a). It is believed that an affirmative decision 
for the Applicant would obviate the pending Requirement. 

Applicant requests that the §112 rejection to the Specification and Claims 
1-30 and 48-51 be overturned as the Examiner has failed to carry the burden of 
proving prima facie case of non- enablement. Applicant appeals for at least the 
following reasons. 

i. Claims 1-30 and 48-50 were in the Application as originally filed and thus 

provide an enabling disclosure for that which is cited therein. 

In the Final Action (below), the Examiner specifically noted that the claims 

at issue were being rejected. 

32. Claims 1-30 and 48-51 are rejected under 35 U.S.C. 112, first paragraph, as failing to comply with 
the enablement requirement. The claim(s) contains subject matter which was not described in the 
specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most 
nearly connected, to make and/or use the invention. The Examiner submits that the specification and 

Final Action of 8/9/06, page 9. 

First, this rejection of Claims 1-30 and 48-51 is improper as Claims 1-30 
and 48-5 1 were in the application as of the filing date (with some amendment to 
Claims 1,16, and 48). Due to the claim's inclusion as of the filing date, the claims 
themselves would form a basis of an enabling disclosure. M.P.E.P. §2164 and 35 
U.S.C. §112, paragraph two. For this reason an "interfacing layer" (asserted as 
missing at Page 10, Paragraph 38) is at least disclosed in as filed Claim 1, which 
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recites "an interfacing layer to interface the problem-solving logic layer with one 
or more resources so that the execution models may utilize the resources when 
processing the client requests." This assertion of a missing "interfacing layer" is 
without merit as Claim 10 further recites wherein the "interfacing layer" 
comprises a data abstraction layer and a data coordination layer. 

This is to say, that while a claim may be invalid if not properly enabled 
within the specification, the only deficiency, if one were to exist, for arguments 
sake, is with the disclosure and not the claims themselves as the Examiner has 
failed to indicate how the claims at issue would not enable themselves. 

Additionally, the Examiner has failed to follow the guidance in M.P.E.P. 
£2164.04 which states, "[b]efore any analysis of enablement can occur, it is 
necessary for the examiner to construe the claims." The record evidences that the 
Examiner did not do this because one reading Claim 10 would be informed that a 
further feature of an "interface layer" was that the layer would include a data 
abstraction layer and a data coordination layer both of which are extensively 
discussed in the written description. 

ii. The Examiner has failed to properly determine the level of one of ordinary skill 
in the art. 

Perhaps, the most telling example of how the Examiner has failed to 
properly apply 35 U.S.C. §112, paragraph one may be best shown in the Final 
Rejection (below), wherein the Examiner's "telephone closet" analogy fails to 
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note that 35 U.S.C. §112, paragraph one, as with §§102 and 103, is viewed from 

the perspective of one of ordinary skill in the art. 
to implement the technical disclosure. A broader, oversimplified analogy could be made to a person wh> 
has being given a detailed schematic of a telephone wiring closet without saying why it is there, what the 
telephone wiring closet actually is, or how it can be used to connect telephones so people can talk to 
each other over them. That person would then be able to read and understand the schematic, but would 
suffer an unreasonable burden in attempting to grasp what the intention is of the device described in the 
schematic and then once the intention was discovered would suffer yet another unreasonable burden in 
actually deciding how the invention could be applied to various environments and implementing the 
.-'invention to fit that inferred application. 

Final Action of 8/9/06, page 9. 
While the Examiner admits that the example is "oversimplified", this 

passage shows that the Examiner has not applied the correct standard for 

enablement because the Examiner has not determined the level of one of ordinary 

skill in the art as required under the Wands Factors. M.P.E.P. £2164.01(a). Thus, 

while the average person on the street may not immediately recognize what the 

schematic discloses, one of ordinary skill in the art, reading the same schematic 

may know precisely the invention's utility, novelty and understand how to 

make/use the invention. This is to say, an electrical schematic conveys volumes of 

information to an undergraduate electrical engineer that may not be apparent to a 

PhD in chemistry. The Examiner's position does not go to the reasons for the 

uncertainty of the enablement but, instead presumes that the person would not 

know why the electrical closet exists or for what purpose the closet serves. 
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iii. The burden is on the Examiner to provide a factual rationale of why the as 
filed Specification fails to meet the enablement standard under 35 U.S.C. §112, 
paragraph one (then and only then does the burden shift to the Applicant to 
present rebuttal arguments). 

The Examiner has failed to carry the burden of proving a prima facie case 
of non- enablement. When rejecting a claim under the enablement requirement of 
Sections 112, the [Patent Office] bears an initial burden of setting forth a 
reasonable explanation as to why it believes that the scope of protection provided 
by the claim is not adequately enabled by the description of the invention provided 
in the specification of the application. . ." In re Wright, 999 F.2d 1557, 27 
USPQ.2d 1510, 1513 (Fed Cir. 1993). The Examiner seemingly argues (below) 
that, because the Examiner cannot understand what the subject matter 
accomplishes then the disclosure must not be enabled, rather then attempting to 
lay out factual assertions or providing evidence buttressing a prima facie case of 
non-enablement. 

nearly connected, to make and/or use the invention. The Examiner submits that the specification and 
claims go into great detail on the technical aspects of the invention. But the Examiner strongly believes 
that the invention cannot be enabled because the Examiner cannot ascertain what the invention is 
attempting to accomplish. The specification refers to various modules, which are swapped out to adapt 

Final Action of 8/9/06, page 9. 

In other words, instead of pointing out what ambiguity exists (such as by 
citing evidence) or citing a violated scientific principle (a reasonable basis), as is 
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required), the Examiner's position merely cites "beliefs" instead of evidence or 
factual findings. M.P.E.P. £2164.04. The Examiner "strong belief that the 
subject matter is not enabled is without merit. The proffered basis for doubting 
enablement is without merit because the Application clearly states, 

"[a] multi-layer software architecture permits efficient and timely 
construction of business processes and server-based software applications for 
many diverse domains, such as business-oriented domains like asset 
management, leasing and lending, inventory tracking, and so forth. The 
architecture is arranged into several hierarchical layers. An execution 
environment layer handles incoming requests from remote clients and selects 
the appropriate problem-solving logic to process the requests. The problem- 
solving logic is organized within a problem-solving logic layer that defines the 
application for a specific problem domain. For individual requests, the logic 
performs various series of tasks to process the requests and produce replies that 
will be returned to the clients. ... 

Any one of the layers may be removed, modified, or updated without 
impacting other layers. This allows the architecture to adapt easily to many 
different problem domains, to support many different types of client devices, to 
accommodate many different users in different regions and cultures of the 
world, and to interface with many diverse resources." Application, Page 3, 
line 14-Page 4, line 10. 

In light of at least this disclosure, the Examiner argument has no basis in- 
fact to bolster the Examiner's "strong belief. 



iv. The Examiner has failed to provide a factual basis for why, at the time of 
the invention, one of ordinary skill in the art would have to conduct an undue 
number of experiments to make/use the invention or provide an objective reason 
why one of skill in the art would doubt the enablement of the specification as 
required under M.P.E.P. £2164.04. 
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While the Final Rejection does reference the Wands Factors (below), the 

rejection does not substantively address the factors. If we assume, for arguments 

sake, that a reason to doubt enablement exists, the Final Action merely recites 

conclusions/assertions without showing how the purported ambiguity renders the 

Application non-enabled. The burden is on the Examiner to prove a case of non- 

enablement under 35 U.S. C. §112, paragraph one rather than on the Applicant to 

disprove assertions or conclusions. M.P.E.P. £2164.04. 

.35. Several factors are considered when determining whether sufficient evidence to support a 
determination that a disclosure is enabled are presented in MPEP 2161 .01 (a). Four of those factors from 
In re Wands, 858 F.2d 731, 737, 8 USPQ2d 1400, 1404 (Fed. Cir. 1988) are found to be lacking. 

36. The breadth of the claims: Applicant failed to provide information in the specification to allow one 
of ordinary skiff in the art to ascertain the scope of the claims. The "domain" definition provided by the 

''specification is never matched with the "problem domains" claimed. 

37. The nature of the invention: Applicant failed to provide information in the specification to allow 
one of ordinary skill in the art to understand the nature of the invention. 

38. The amount of direction provided by the inventor: Applicant failed to provide direction So allow 
jone of ordinary skill in the art to understand how to implement the invention by failing to relate the 
invention to fields of art known to one of ordinary skill. For example, Applicant never included content 
relating to an interfacing layer in the originally filed specification. This failure immediately calls into 
question whether the disclosure when filed contained sufficient information regarding the subject matter of 
the claims as to enable one skilled in the pertinent art to make and use the claimed invention based on 
jthe test of enablement in MPEP 21 64.01 . 

39. The quantity of experimentation needed to make or use the invention based on the content of the 

disclosure: Applicant failed to define multiple terms in the claims. Applicant did not provide any 

j 

assistance in understanding the layering in the invention orlfte scope of the domains. One of ordinary 
skill in the art would suffer the burden of undue experimentation in understanding and implementing the 
invention based upon the amount of material lacking within the specification as originally filed. 
Final Action of 8/9/06, pages 10-11. 
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In the instances in which the Examiner does recite potential rationales 
(Items 36 and 38), the Examiner fails to carry the burden of showing why these 
items are a problematic. Terms of a claim carry "their ordinary meaning, unless it 
appears that the inventor used them differently." Gargoyles Inc. v. United States 
28 USPQ 2d 1715, 1716-17 (Fed. Cir. 1993). For example, instead accepting a 
plain meaning of term "problem" "domain" as a domain having a problem (as 
argued by the Applicant), in Item 38 (above), the Examiner merely asserts the 
factor is not met and then moves on. 

Considering Item 38, there is no problem finding variations of the term 
"interface" as this term appears at least 34 times in the Written Description. This 
includes references describing "layers" and "interface" at Application, Page 3, line 
27; Application, Page 10, line 19; Application, Page 12, line 1; Application, Page 
12, line 11; Application, Page 13, line ¥;and so on. Also, quite notably, the term 
"interface layer" appears in Claim 10. Claim 10 states (emphasis added), 

"A server system as recited in claim 1, wherein the interfacing layer 
comprises: 

a data abstraction layer to obtain data from the resources and map the data 
into a domain framework that models information flow for a specific problem 
domain; and 

a data coordination layer that provides an interface for the problem-solving 
logic layer to access the domain framework of the data abstraction layer and 
obtain the data." 
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Additionally, the Examiner's own arguments contradict the Examiner's 
position as to the direction provide by the inventor. Applicant directs the Board's 
attention to the Final Action, Page 9 (below), wherein the Examiner states, that the 
specification and claims "go into great detail". Apparently, the Examiner would 
have us believe that there is too much detail in one instance and then have us 
believe that this "great detail" fails to "provide direction to allow one of ordinary 
skill in the art to understand how to implement the invention." 

nearly connected, to make and/or use the invention. The Examiner submits that the specification, and 
claims go into great detail on the technical aspects of the invention. Bui the Examiner strongly believes 

Final Action of 8/9/06, page 9. 

The Examiner has not provided objective reasons/evidence for doubting the 
enablement of the Application. Specifically, Items 37 does not provide a rationale 
why one of ordinary skill in the art could not understand the disclosure, but instead 
merely recites the conclusion. For example, the Examiner has failed to indicate 
what teaching is missing. In the end, in-lieu of providing substantive rationale 
which the Applicant may rebut, the Examiner merely asserts that four (out of 
eight) of the Wands factors, and presents some rationale in (perhaps) three out of 
four of the proffered Wands factors. 

Accordingly, claims 1-30 and 48-51 and the Specification satisfy the 
requirements of 35 U.S.C. § 112, paragraph one and therefore it is respectfully 
requested the rejection of these claims be overturned. Additionally, the 
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Requirement for a Substitute Specification under 37 CFR 1.125(a) is improper and 

should be obviated in light of the Boards decision in regards to 35 U.S.C. §112, 

paragraph one. Additionally, the Examiner's citation of 37 CFR 1.125(a) is 

improper as the section merely authorizes the following, 

"If the number or nature of the amendments or the legibility 
of the application papers renders it difficult to consider the 
application, or to arrange the papers for printing or copying, the 
Office may require the entire specification, including the claims or 
any part thereof, be rewritten." 37 CFR 1 .125(a) 

2. SECOND GROUND OF REJECTION: 

Claims 1-30 and 48-51 satisfy the requirements of 35 U.S.C. § 112, second 
paragraph. 

Applicant requests that the §112 rejection to Claims 1-30 and 48-51 be 
overturned as the Examiner has failed to carry the burden of proving prima facie 
case indefiniteness under 35 U.S.C. §1 12, paragraph two. Applicant appeals for at 
least the following reasons. 

i. The Examiner has ignored the plain meaning of the claim terms. In the 
Final Action the Examiner rejected the at issue claims under the following basis, 

1357, 52 USPQ2d 1029, 1033 {Fed. Cir. 1999). With regard to claims 1-53, Applicant has freely acted as 
**his own lexicographer. Applicant has used multiple terms that are not well known in the art and the 
Examiner has not encountered satisfactory definitions for said terms within the specification or within the 
prior art, including multiple technical and computer dictionaries, as to clear up this deficiency. The 

Final Action of 8/9/06, page 11. 
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In other words, the Examiner would have us believe that the Applicant is 
acting a lexicographer (one who provides definitions) and to prove the Examiner's 
position, the Examiner asserts that no definitions are given in the Specification. 
This argument is circular because by "definition" a lexicographer must provide 
"definitions" or else they are not a lexicographer. This type of argument is akin to 
the story of the person, in North America, who upon hearing hoof-beats presumes 
that a herd of zebras is about, instead of horses. In this case, the Examiner has 
failed to apply the presumptively correct plain meaning of the claim terms. 
Additionally, the Examiner has failed to construe the claim terms and instead asks 
that the Applicant construe the claim terms (below). 

4. Until Applicant is willing to clarify on the record what the invention actually is for the Examiner, no 
reasonable search of the prior art can be undertaken. Several Senior Examiners have been consulted 
within the Office in an attempt to clarify the invention, which is evidence contrary to Applicant's assertion 
*'on page 31 of the remarks that "others were not similarly stymied by the kind of exposition provided by 
the present application. This observation has at least a bearing on how the present application would be 

Final Action of 8/9/06, page 2. 
Thus, rather than construing the claims broadly and presenting a prima 
facie case that the as understood definition is indefinite in accordance with 
M.P.E.P. §2 173.05(a), or that an alternate definition exists, the Examiner merely 
asserts that the Applicant is acting as a lexicographer and ask the Applicant to 
provide definitions. For example, instead of using the plain meaning of the term 
"interfacing layer" as a layer, or a thickness or course, that interfaces or interacts 
at a boundary and then looking to the claims that depend from Claim 1 to see if the 
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genius of "interfacing layer" is further described, the Examiner merely states that 
the term is indefinite. If the Examiner had properly construed the claim term, the 
Examiner would have been apprised that (with respect to Claim 1) Claim 10 
further recites that an "interfacing layer" 

comprises: 

a data abstraction layer to obtain data from the resources and map the data 
into a domain framework that models information flow for a specific problem 
domain; and 

a data coordination layer that provides an interface for the problem- solving logic 
layer to access the domain framework of the data abstraction layer and obtain the 
data. 

With this inherent definition (although in a narrower form) , the Examiner 
could have found that the written description discussed interfacing layer at least 
page 12, line 1 to page 13, line 24. In the alternative, the Examiner could have 
used the "Exemplary and Non-limiting Support for Claims in Specification" 
provided with the Response filed 4/28/06. 

Instead, the Examiner merely selected to hold both Claims 1 and 10 
indefinite. In much the same vein, as 35 U.S.C. §112, paragraph one, the 
Applicant is not obliged to disclose definitions for instances in which the plain 
meaning of terms follow idiomatic American English as would he understandable 
to one of ordinary skill in the art. This process is greatly hampered by the fact that 
the Examiner did not establish the characteristics of one of ordinary skill in the art. 
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The Examiner's argument is false as the position ignores the plain meaning of the 
claim terms (as argued by the Applicant) in-favor of hidden definitions which are 
1) not present in the Specification or 2) not in "unspecified" "multiple technical 
and computer dictionaries". The Examiner's position ignores the fact that the 
plain meaning of the term is intended, and thus no definition is necessary. At no 
time has the Examiner asserted that the Applicant seems to be using a word in a 
contradictory manner from the word's standard American English meaning, e.g., 
"up" in place of "down", "black" in place of "white." The Examiner's position 
fails to provide a rationale why the term is used in a non-standard way or even 
what is the applicable level of one of ordinary skill in the art. 

Applicant is at a loss to combat an Examiner's un-cited assertion that a 
definition does or does not exist in an unnamed "multiple technical and computer 
dictionaries". Final Action of 8/9/06, pagell. Applicant is similarly at a loss to 
rebut the unsubstantiated reference to the consultation of "Several Senior 
Examiners" in the Final Office Action page 2 (above) as the Examiner has failed 
to provide affidavits under 37 C.F.R. 1.104(d)(2) from these "Several Senior 
Examiners" 

The Examiner goes on to cite (by counsel's count) 42 terms and phrase 
(below) with which the Examiner takes issue. As the Examiner's position did not 
specifically state which claims were being rejected, it is believed that no separate 
recitation of each dependent claim is due in the Summary of Claimed Subject 
Matter section. 
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prior art, including multiple technical and computer dictionaries, as to clear up this deficiency. The 
following are some of the terms that the Examiner has encountered within the claims that are not well 
known in the art, but this list is not meant to be limiting in that regard: muiti-layer application, probiem- 
solving logic layer, problem domain, execution mode!, execution environment layer, interfacing layer, 

framework, model dispatcher, request dispatcher, interaction-based model, interaction definitions, 
command model, action-view model, use case model, data abstraction layer, data coordination layer, 
''domain framework, application data manager, application solution space, layout of individual replies, 
presentation theme, presentation module, rendering module, constraint system, hierarchy of constraint 
layers, constraint hierarchy, constraint resolver, legally mandated constraints, company-mandated 
constraints, cultural constraints, cultural aspects, low-level security rules, high-level permission concepts, 
form processor, form definition, resource bundle, locale-specific content, locale, resource bundle 
manager, locale-independent core, locale-sensitive content, computer-servabfe document. The terms are 
indefinite because the specification does not clearly define the terms to the extent required by the 
Examiner in order to allow one of ordinary skill in the art to reasonably understand the specification and 
invention with ease and clarity. 

Final Action of '8/9/06, pages 11-12. 

Taking the first phrase "multi-layer application" the Final Action fails to 

apply the plain meaning of the phrase (such as a computer type program having 

multiple layers or levels) but instead merely states the claim terms do not meet the 

Examiner's subjective satisfaction (what the Examiner thinks one of ordinary skill 

in the art would know). 

manager, locale-independent core, locale-sensitive content, computer-servable document. The terms are 
indefinite because the specification does nol clearly define the terms to the extent required by the 
Examiner in order to allow one of ordinary skill in the art to reasonably understand the specification and 

invention with eaSfi and filarhv 

Final Action of 8/9/06, pages 11-12. 
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Applicant respectfully asserts that the remaining claim terms utilize plain 
ordinary meanings associated with the given words as understood by one of 
ordinary skill in the art. Further, the Examiner's determination is done without 
resolving the level of one of ordinary skill in the art, such as in a biotech area, 
asserting that the level of ordinary skill in the art is a person with a master's in 
biology and then go on to explain why a biotech term would not be understood by 
the "one of ordinary skill in the art" 

While not obligated under prosecution guidelines, Applicants' reply of 
April 28, 2006, went so far as to include an "Exemplary and Non-limiting Support 
for Claims in Specification" Appendix cross-referencing claim terminology with 
portions of the written description. 

ii. The Examiner's position is not supported on the record. The Examiner 
issued a Restriction Requirement (below) without any assertion that the claim 
terminology was indefinite. This rejection did not even attempt to equivocate on 
the definiteness of the claim terms, such as by asserting (hypothetically) "as best 
understood by the Examiner". 
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Election/Restrictions 
1 . Restriction to one of the following inventions is required under 35 U.S .C. 1 21 : 

t. Claims 1 -30 and 48-52, drawn to a multi-layer application executing on a 

computer with a problem-solving layer, classified in class 709, subciass 203. 

II. Claims 31-47, drawn to a business-oriented computer software architecture with 
a business logic module, classified in class 705, subclass 39. 

III. Claims 52-57 , drawn to a method for creating server applications for multiple 
different domains, classified in class 717, subclass 106. 

The inventions are distinct, each from, the other because of the following reasons: 
2 Inventions I, II and 111 are related as subcombinations disclosed as usable together in a 
single combination. The subcombinations are distinct from each other if they are shown to be 
separately usable. In the instant case, invention 1 has separate utility such as a multi-layer 
application executing on a computer with a problem-sotving layer, but lacks a business logic 
module and creating server applications. Invention II has separate utility as a business-oriented 
computer software architecture with a business logic module, but lacks a problem-solving layer 
and creating server applications. Invention 111 has separate utility as a method for creating server . 
applications for multiple different domains, but lacks a business logic module and a multi-layer 
application. See MPEP § 806.05(d). 

3. Because these inventions are distinct for the reasons given above and have acquired a 
separate status in the art as shown by their different classification, restriction for examination 
purposes as indicated is proper. 

4. Because these inventions are distinct for the reasons given above and the search 
required for Group 1 is not required for Groups II and III, restriction for examination purposes as 
indicated is proper. 

5. A telephone call was made to Lewis C. Lee on December 9, 2004 to request an oral 
election to the above restriction requirement, but did not result in an election being made. 

Restriction of 12/21/04, page 3.. 
Thus, the Examiner's present argument is inconsistent with the Examiner's own 
Restriction Requirement which was able to resolve 1) the separate utility, 2) the 
distinctiveness of the claims in the various groups. 

Accordingly, claims 1-30 and 48-51 satisfy the requirements of 35 U.S.C. § 
112, paragraph two (defmiteness) and therefore it is respectfully requested the 
rejection of these claims be overturned. 
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3. THIRD GROUND OF REJECTION: 

The drawings comply with 37 CFR 1.81(a) and are therefore in compliance 
with 35 U.S.C. §113, first sentence. Accordingly, the Objection of the drawings 
under 37 CFR 1.81(a) is improper. This matter is properly in front of this Board 
as the Examiner's Objection incorrectly implicates 35 U.S.C. §113 first sentence 
requiring drawings where "necessary" rather than drawings under 37 CFR 1.81(c). 

The relevant portion of the Examiner's Final Action is reproduced below 

for the Office's convenience. As stated at Final Action, Page 7, 

28. The drawings are objected to because, though the drawings are comprehensive in nature and 
cover multiple aspects of the invention, the drawings still fail to convey to one of ordinary skill in the art 
what exactly is being accomplished by the invention. The closest drawing that the Examiner feels is to 
"showing the actual usage of the invention, which is still unclear, is Figure 20, which shows a login prompt 
on a web page and a human translator. Even with these two items present in Figure 20, and the 
descriptions given for this and all other submitted drawings, the Examiner is not assisted in grasping the 
invention at all based upon the currently submitted drawings. Applicant is reminded of the necessary 
compliance with 37 CFR 1 .81 (a), which states The applicant for a patent is required to furnish a drawing 
of his or her invention where necessary for the understanding of the subject matter sought to be 
patented; this drawing, or a high quality copy thereof, must be filed with the application. Since 
corrections are the responsibility of the applicant, the original drawing(s) should be retained by the 
applicant for any necessary future correction. [Emphasis added by the Examiner.] Corrected drawing 

i. As the drawings have not been omitted, the Objection under 37 CFR 

1.81(a) is improper. 

The Examiner incorrectly contends that the basis of the drawing objection 

lies in "37 CFR 1.81(a)". The Examiner is incorrect because as discussed in 
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M.P.E.P. § 608.02 (III) "[a] drawing will be considered necessary under the first 
sentence of 35 U.S.C. §113 in all applications where the drawing is referred to in 
the specification and one or more figures have been omitted ." Emphasis added. 
Thus, the Examiner has ignored the Office's own understanding of 35 U.S.C. 
§113, first sentence by invoking 37 CFR 1.81(a), which mirrors the first sentence 
of 35 U.S.C. §113. As the Examiner has not asserted that drawings are omitted, 
the citation of 37 CFR 1.81(a) and by implication 35 U.S.C. §113, first sentence is 
improper. 

ii. The record supports the Applicant's position regarding the necessity of 
drawings under 37 CFR 1.81(a) and by implication 35 U.S.C. §113. 

As the Board is well aware, the Office of Initial Patent Examination (OIPE) 
makes initial decisions as to the applicability of 35 U.S.C. §113, first sentence and 
thus, decisions with regard to 37 CFR 1.81(a). By passing the Application on for 
examination, the OIPE determined that the drawings met 35 U.S.C. §113 and 37 
CFR 1.81(a). 

For arguments sake, if we presume the Examiner has correctly applied 37 
CFR 1.81(a), the Examiner failed to follow proper procedures in M.P.E.P. § 
608.02 (III) or, in the alternative, failed to cite a proper basis in M.P.E.P. § 608.02 
(IV). 

iii. The Examiner has failed to follow the Office's guidance regarding the 
necessity of drawings as at least one of the claims at issue recites a method. 
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The Examiner has not followed the guidance in M.P.E.P. § 608.02 (III) 
which states "A drawing is not required for a filing date under 35 U.S.C. §§111 
and 113 if the application contains; (A) at least one process claim including the 
term "process" or "method" in its introductory phrase;" 

At least Claim 48, as filed, recited "A method", so a drawing is not required 
in this case. 

iv. The Examiner has failed to provide any rationale, legal or factual, why one 

of ordinary skill in the art cannot understand the drawings. 

The Examiner's contentions fail to provide any rationale, legal or 

otherwise, to bolster the Examiner's position. The Examiner contentions failed to 

give a factual reason (beyond the drawings are too complete, see below) why the 

drawings are deficient. Instead, the Examiner position merely "jumps to the 

conclusion" that "the drawings still fail to convey to one of ordinary skill in the art 

what exactly is being accomplished by the invention" instead of laying a factual or 

legal basis for support the Examiner's position under 35 U.S.C. §113 and 37 CFR 

1.81(a). Thus, Applicant is only provided the following general assertion, 

28. The drawings are objected to because, though the drawings are comprehensive in nature and 
cover multiple aspects of the invention, the drawings still fail to convey to one of ordinary skill in the art 
what exactly is being accomplished by the invention. The closest drawing that the Examiner feels is to 
"showing the actual usage of the invention, which is still unclear, is Figure 20, which shows a login prompt 
on a web page and a human translator. Even with these two items present in Figure 20, and the 

Final Action, Page 7. 
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The Examiner has failed to provide any legal rationale (including a citation 

of applicable statute, rule or guidance) which would require the Applicant to 

furnish drawings based on the Examiner's subjective "feeling". Additionally, the 

Examiner's own statement indicating that the drawings are " comprehensive in 

nature and cover multiple aspects" (emphasis added) is inconsistent with the 

contention that the information does not convey information in accordance with 35 

U.S.C. §113, first sentence and 37 CFR 1.81(a). 

com.pre-hen.slve Vkam-pri-'hen-sivV 
adj i covering completely or broadly <^ 
insurancc> — com-pre-hen-sive-ly adv 
— com.pre'hen*sive*ness n 

Merriam Webster Dictionary: New Addition, Springfield, MA 1 48 (2004). 

Counsel for Applicant presumes that the first definition is intended as the 
"covering multiple aspects portion" of the sentence would be redundant. 

Accordingly, the drawings satisfy the requirements of 35 U.S.C. § 1 13, first 
sentence and 37 CFR 1.81. Therefore, Applicant requests the Objection be 
obviated based on the determination that the drawings satisfy the requirements of 
35 U.S.C. § 1 13, as the Examiner is required to cite more than a feeling to support 
a prima facie case under 37 CFR 1.81(a) and/or 35 U.S.C. §113, fist sentence. 

4. FOURTH GROUND OF REJECTION: 

Claims 1-9, 12-16, 18-21, 23-24, and 48-51 satisfy the requirements of 35 

U.S.C. § 102(b) and therefore are not anticipated by Stevens. 
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i.) Stevens fails to disclose a server having a multi-layer application including 
a problem solving logic layer, an execution environment layer, and an interfacing 
layer. 

With respect to Claim 1, the difference in opinion between the Examiner 
and the Applicant is whether Stevens discloses a server having a multi-layer 
application. Applicant's position is that Steven does not disclose multiple layers, 
because the inetd daemon, included in a "superserver" is not described as having 
the three layers in addition to a "presentation layer" (i.e., a problem solving logic 
layer, an execution environment layer, and an interfacing layer, beyond a 
presentation layer) in which a change in one layer does not affect another layer as 
generally recited. 

In contrast to the presently recited system, Stevens discloses an inetd 
daemon, which is a process which operates in the background. Stevens, Page 72. 
In a given example, an inetd daemon is a line printer process which waits for a 
specified period or until a specified event occurs. Id. A superserver is described 
which implements a single inetd daemon. Stevens, Page 335. In this way, the 
single inetd process waits to serve multiple requests instead of setting up a process 
for each potential service. Id. The inetd processes the initial requests prior to 
utilizing the server. Id. The inetd does this by executing a fork and exec. Id. A 
fork permits the parent to exit and allows the child process to continue to handle 
the daemon. Stevens, Pages 74, bottom of page to Page 75, top of page. In this 
manner, a request is handed off to the child for processing. Stevens, Pages 334 
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and 335. A presentation layer may be included to modify the representation to 
promote exchange. Stevens, Page 250. 

The Examiner's final action fails to indicate how the inetd daemon could 
anticipate the present subject matter, as Stevens only describes a parent-child 
relationship and a presentation layer. As discussed by the Applicants above, the 
Stevens system does not anticipate the present claim because Stevens does not 
disclose "layers." Stevens has only 1) a parent, 2) a child in addition to a 
presentation layer, while Claim 1 in part recites 1) a problem solving logic layer, 
2) an execution environment layer, 3) an interfacing layer, and a presentation 
layer. 

ii. Stevens fails to disclose an application in which any of the layers may be 
changed without impacting other layers. 

The Final Action fails to point out how the parent process and the child 
process, as disclosed in Stevens, meets the features recited in Claim 1. The 
pending rejection has failed to cite where Stevens discloses wherein any of the 
layers may be changed without impacting other layers or how inetd is capable of 
permitting layer changes without impacting the entirety of the inetd (asserted as 
being the execution environment layer, the interfacing layer, the problem-solving 
logic layer). Instant Action, Page 5, Paragraph 18. "Inherency. . .may not be 
established by probabilities or possibilities. The mere fact that a certain thing may 
result from a given set of circumstances is not sufficient." In re Oelrich, 666 F.2d 
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578,581, 212 USPQ 323, 326 (C.C.P.A. 1981) citing Hansgirg v. Kemmer, 102 
F.2d 212, 214, 40 USPQ 665, 667 (C.C.P.A. 1939). Emphasis added. Stevens 
does not address the issue of layer variation within the referenced excerpts. In 
Stevens, the parent process cannot be changed without impacting the child, as the 
child process inherits a configuration file passed from the parent. Stevens, Page 
238. Additionally, a daemon process inherits its file access creation mask from its 
parent. Stevens, Page 74, Paragraph "Reset the File Access Creation Mask," In 
this manner, the parent and child are intertwined, such that a change within the 
parent impacts the child. 

iii- Claims 2-9, 12-16, 18-21, 23-24 depend either directly or indirectly from 
Claim 1 and are allowable as depending from an allowable base claim, as well as 
for their own recited features. Each of these claims depends from Claim 1 and is 
therefore allowable for reasons discussed with respect to Claim 1 . These claims 
are also allowable for their own recited features which, in combination with those 
recited in Claim 1, are not disclosed in the references of record, 
iv. Claim 20 is allowable based on its dependence from Claim 1. Claim 20 
additionally recites features which are not disclosed in the art of record. Claim 20 
in part recites a constraint system to constrain operation of the multi-layer 
application . . . comprising a hierarchy of constraint layers . . . with each constraint 
layer containing a set of one or more constraints that customize operation of the 
multi-layer application. In the previous Responses, Applicant argued that, 
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"Stevens does not disclose or suggest a constraint system that constrains the 
operation of a multi-layer application, where the constraint system is comprised of 
a hierarchy of constraint layers." The Final Action identifies Steven's 
configuration file (disclosed on pages 335-336) as having a bearing on this feature. 
However, the configuration file merely specifies the services that the superserver 
is to listen for and what to do when a service request arrives. It does not comprise 
a hierarchy of constraints. Response 4/28/06, Page 41. 

In the Final Action, Page 5, Paragraph 20 (reproduced below) the Office 
merely asserts a hierarchy of constraints and customization is disclosed without 
citing any portion of the reference for this teaching, as is required. Stevens fails to 
disclose a hierarchy of constraints, either at pages 335-336 or anywhere else. The 
cited passage from Stevens is limited to discussing establishing the inetd daemon, 
which includes a list of fields. Stevens, Pages 335. This /etc/inetd.conf file is 
simply a list of services that the superserver is to listen for, rather than establishing 
a hierarchy of constraint layers. Id. In each case, the superserver waits until one 
of the requests arrives, rather than establishing a hierarchy of services. In this 
way, the superserver may be triggered by any of the requests and does not utilize a 
hierarchy. Instead, Stevens discloses a list of requests which can trigger the 
superserver. As a prima facie case of anticipation has not been shown, reversal of 
the pending rejection is requested. 
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20. In regard to claim 20, Stevens has disclosed a hierarchy of constraints, given the broadest 
reasonable interpretation of the ciaim lang-sge per MPEP 2111.01 , Customization is taught throughout 
Jstevens. 

Final Action, Page 5. 



v. Claim 48 recites in part, a method generally including "receiving requests 
from multiple clients, the requests being related to a business -related problem 
domain, wherein the business-related problem domain pertains to a particular 
category of business-related service", "retrieving the data from one or more 
external resources and mapping the data to a domain framework for the business- 
related problem domain, the domain framework being independent from the 
problem-solving logic" and "wherein a new business-related problem domain can 
be exchanged for a previous business-related problem domain by replacing one or 
more components of the system, without having to reconstruct an entire 
application solution for the new business-related problem domain." Steven fails to 
teach the recited features for at least the following reasons. 

As discuss generally with respect to Claim 1 (above), the Stevens 
superserver system does not disclose replacing one or more components of the 
system without having to reconstruct an entire application. In Stevens, the parent- 
child process relationship is such that the child inherits its file access creation 
mask and configuration file from the child process' parent. In this way, a 
replacement of the parent impacts the child. 
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Stevens also fails to teach business-related problem domains. The Stevens 
reference does not address the feature of a "business-related" problem or a 
"particular category of business-related service." Examples of business domains 
include, but are not limited to, financial management, asset repair, or inventory 
tracking domains. Instant Application, Page 6, lines 5-14. "An anticipating 
reference must describe the patented subject matter with sufficient clarity and 
detail to establish that the subject matter existed and that its existence was 
recognized by persons of ordinary skill in the field of invention." ATD Corp.v. 
Lydall, Inc., 48 USPQ.2d 1321,1328 (Fed. Cir. 1998) citing In re Spada, 15 
USPQ.2d 1655, 1657 (Fed. Cir. 1990). Emphasis added. Stevens fails to meet the 
requirements, as the reference does not teach "business -related problem domain" 
or replacing one or more components . . . without having to reconstruct and entire 
application solution. 

vi. Claims 49-51 depend either directly or indirectly from Claim 48 and are 
allowable as depending from an allowable base claim, as well as for their own 
recited features. Each of these claims depends from Claim 48 and is therefore 
allowable for reasons discussed with respect to Claim 48. These claims are also 
allowable for their own recited features which, in combination with those recited 
in Claim 48, are not disclosed in the references of record. 
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For at least the foregoing reasons, Claims 1-9, 12-16, 18-21, 23-24, and 48- 
51 satisfy the requirements of 35 U.S.C. § 102(b) and therefore are not anticipated 
by Stevens. Accordingly, it is respectfully requested that the second ground of 
rejection be overturned. 

5. FIFTH GROUND OF REJECTION: 

Claims 10, 11, 17, 22, 25-30 and 58 satisfy the requirements of 35 U.S.C. § 

103(a) and therefore are not rendered obvious by the below combinations. While 
the Supreme Court's recent Teleflex Decision modified the Teaching, Suggestion, 
Motivation Test away from a rigid rule, the Court's decision did not change settled 
law that the Examiner must provide a rationale for why one of ordinary skill in the 
art, at the time of the invention, would have made the proposed substitution, as 
well as meeting the all elements rule. KSR International Co. v. Teleflex, 550 U.S. 
unknown, 04-1350, 1 14 (2007). As discussed below, the Examiner has failed to 
meet the requirements for establishing a prima facie case of obviousness including 
the motivation to combine. 

i. The Examiner has failed to meet the all elements requirement embodied in 
35 U.S.C. § 103(a) and has failed to state a motivation to combine sufficient to 
meet the requirements under the law. Claims 10, 11, and 58 are rejected over 
Stevens in view of Gilly. 

While Claim 10, is indicated as pending a rejection over Stevens in view of 

Gilley, the text of Paragraph 21, Page 5, the "Response to Arguments" section of 

the final action rejecting Claim 10 is directed to asserting the specification lacked 
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a sufficient disclosure of an "interfacing layer." Applicants disagree. While 
addressed above, an "interfacing layer" is at least discussed generally at Page 3, 
line 20 through Page 4, line 10, as well as, Page 12 through line 24. Moreover, 
while paragraph 21 discloses that a broad interpretation will be used, the Office 
fails to state how the cited references make the subject matter of Claim 10 
obvious. Neither of the references teach or suggest an interfacing layer including 
a data abstraction layer and a data coordination layer as claimed. Additionally, 
paragraph 71, discussing Claims 10-11 fails to provide any citation of either a data 
abstraction layer or a data coordination layer or evidence, supporting a motivation 
to combine. 

71 . Regarding claims 10-11, Stevens is applied as in claim 1 . Stevens fails to disclose data 
jconversion. However, Gilly discloses methods of converting data in the UNIX system. See Gilly, 10-1 - 
11-11. It would be obvious to one of ordinary skill in the art to convert data in order to allow various 
server processes to accept the requests as specifically required by the preexisting server processes. By 
this rationale claims 10-11 are rejected. 

Final A ction, Page 17. 

As the Supreme Court noted in the recent Teleflex decision, "[Rejections 
on obviousness grounds cannot be sustained by mere conclusory statements; 
instead, there must be some articulated reasoning with some rational underpinning 
to support the legal conclusion of obviousness." KSR International Co. v. 
Teleflex, 550 U.S. unknown, 04-1350, 1 14 (2007). 
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As a prima facie case of obviousness has not been shown with respect to 
Claims 10 and 1 1, reversal of the pending rejection is requested. 

The pending rejection under 35 U.S.C. § 103(a) to Independent Claim 58 
should be reversed as the Examiner has failed to establish a prima facie case of 
obviousness over Stevens in view of Gilly. The entirety of the Examiner's 
rejection specifically directed to Claim 58 (under 35 U.S.C. § 103(a)) appears in 
paragraph 72 which cites, 

72. Claim 53 contains the same substantive language as claims 1 and 1 0. 

Final Action, Page 17. 

Applicant disagrees. First, the Examiner has failed to prove a prima facie 
case of obviousness because Stevens system does not teach "layers." Stevens has 
only 1) a parent, 2) a child, in addition to a presentation layer, while Claim 58 in 
part recites 1) a problem solving logic layer, 2) an execution environment layer, 3) 
an interfacing layer (comprising a data abstraction layer and a data coordination 
layer), and a presentation layer. To establish prima facie obviousness of a claimed 
invention, all the claim limitations must be taught or suggested by the prior art. In 
re Ryoka, 180 U.S.P.Q. 580 (C.C.P.A. 1974). See also In re Wilson, 165 U.S.P.Q. 
494 (C.C.P.A. 1970 

Moreover, the Examiner's rejection fails to lay out a prima facie case of 
obviousness, as the Board is well aware, the examiner "ordinarily should reject 
each claim on all valid grounds available." M.P.E.P. §707. 07(g) Further, "[wjhere 
a major technical rejection is proper, it should be stated with a full development of 
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reasons rather than by a mere conclusion coupled with some stereotyped 
expression." Id. ). As a prima facie case of obviousness has not been shown with 
respect to Claim 58, reversal of the pending rejection is respectfully requested. 

iii. The Examiner has failed to meet the all elements requirement embodied in 
35 U.S.C. § 103(a) and has failed to state a motivation to combine sufficient to 
meet the requirements under the law with respect to Claim 17. Claim 17 is 
pending a 35 U.S.C. § 103(a) rejection over Stevens in view of Official Notice. 
Claim 17 in part recites, 

wherein the presentation layer comprises: 

• a presentation module to determine how the replies will appear on the 
client devices to users; and 

• a rendering module, separate from the presentation module, to determine 
how to render the replies on the client devices. 

In the case of Claim 17, the Examiner has not cited Official Notice for the 
missing layers, thus as discussed with regard to Claim 1 under 35 U.S.C. § 102(b), 
Stevens fails to show 1) a problem solving logic layer, 2) an execution 
environment layer, 3) an interfacing layer, and a presentation layer. Stevens only 
discloses 1) a parent, 2) a child, in addition to a presentation layer. 

Additionally, the Examiner has failed to proffer Official Notice as 
correcting the failure of Stevens to teach "wherein any of the layers may be 
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changed without impacting other layers". As Stevens teaches a parent process- 
child process, the parent process cannot be changed without impacting the child, 
as the child process inherits a configuration file passed from the parent. Stevens, 
Page 238. In this manner, the parent and child are interconnected, so that a change 
within the parent will impact the child. This is in contrast to Claim 17, which due 
to its dependency on Claim 1, discloses, "wherein any of the layers may be 
changed without impacting other layers." 

More particular to Claim 17, Examiner has failed to assert that one of skill 
in the art would have known to bifurcate a presentation layer into a presentation 
module and a separate rendering module. This is to say, that there has been no 
showing that one of skill in the art would have known to have a presentation layer 
including a presentation module and a rendering module, separate from the 
presentation module and a motivation to do so. Additionally, the Examiner has 
failed to provide any evidence for the imposition of Official Notice or for a 
motivation to combine. Applicants challenged the Office's application of Official 
Notice in Applicant's Reply of September 12, 2005, Pages 35 & 36. 

In regards to Claim 17, the Examiner has failed to elaborate a rationale 
sufficient to meet the Supreme Court's guidance. As the Court noted, "[^ejections 
on obviousness grounds cannot be sustained by mere conclusory statements; 
instead, there must be some articulated reasoning with some rational underpinning 
to support the legal conclusion of obviousness." KSR International Co. v. 
Teleflex, 550 U.S. unknown, 04-1350, 1 14 (2007). 
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67. In regard to claim 17, Stevens is applied as in claim 1 . Stevens discloses a presentation module 
to determine how the replies will appear on the client devices to users. See Stevens, 250. Stevens fails 
to disclose a rendering module, otherwise known in the art as a program to assist in displaying 

information. However, Official Notice is taken thai displaying information on a screen has been well 
^known in the art for decades. It would be obvious to one of ordinary skill In the art at the time of the 
invention to display the information from a computer request on a screen so a user could see the results 
of the computer request. By this rationale claim 17 Is rejected. 

Final Action, Page 16-17. 

In the present instance, the Examiner has failed to provide evidence of the 
existence of a rendering module, separate from the presentation module , and 
evidence of the motivation to make this combination. Thus, while the Examiner 
may cite the common sense of one of ordinary skill in the art at the time of the 
invention, there must be some evidence supporting the Examiner's assertion. As a 
prima facie case of obviousness has not been shown, reversal of the pending 
rejection is requested. 

iii. The Examiner has failed to meet the all elements requirement embodied in 
35 U.S.C. § 103(a) and has failed to state a motivation to combine sufficient to 
meet the requirements under the law with respect to Claim 22. Claim 22 is 
pending a 35 U.S.C. § 103(a) rejection over Stevens (alone). 

While the Examiner is correct that Stevens fails to teach all the features of 
Claim 22, the Examiner is incorrect that 1) there is motivation to look beyond 
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Stevens and 2) the recited features are within the knowledge of one of ordinary skill 
in the art. First, the Examiner has failed to cite the knowledge of one of ordinary 
skill in the art as correct the following deficiencies in Stevens 1) a problem solving 
logic layer, 2) an execution environment layer, 3) an interfacing layer, and a 
presentation layer. Stevens only discloses 1) a parent, 2) a child, in addition to a 
presentation layer. 

Stevens fails to teach or suggest wherein any of the layers may be changed 
without impacting other layers or how inetd is capable of permitting layer changes 
without impacting the entirety of the inetd (asserted as being the execution 
environment layer, the interfacing layer, the problem-solving logic layer). "[I]t is 
necessary to ascertain whether the prior art teachings would appear to be sufficient 
to one of ordinary skill in the art to suggest making the claimed substitution or 
other modification." In re Lalu, 741 F.2d 703, 223 USPQ 1257, 1258 (Fed. Cir. 
1984). In the present case, as the knowledge of one of ordinary skill in the art is 
not cite as correcting this deficiency a prima facie case of obviousness does not 
exist as not all the elements have been shown. 

Additionally, Stevens fails to teach or suggest a hierarchy of constraints, 
either at pages 335-336 or anywhere else. Stevens is limited to discussing 
establishing the inetd daemon, which includes a list of fields. Stevens, Pages 335. 
This /etc/inetd.conf file is simply a list of services that the superserver is to listen 
for, rather than establishing a hierarchy of multiple constraint layers. Id. In each 
case, the superserver waits until one of the requests arrives, rather than 
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establishing a hierarchy of services. In this way, the superserver may be triggered 
by any of the requests and does not utilize a hierarchy. Instead, Stevens discloses 
a list of requests which can trigger the superserver. As a prima facie case of 
obviousness has not been shown, reversal of the pending rejection is requested. 

iii. The Examiner has failed to meet the all elements requirement embodied in 
35 U.S.C. § 103(a) and has failed to state a motivation to combine sufficient to 
meet the requirements under the law with respect to Claims 25-28. 

Claims 25-28 are pending a 35 U.S.C. § 103(a) rejection over Stevens in 
view of Peek. Claims 26-28 depend from Claim 25 and are allowable as 
depending from an allowable base claim, as well as for their own recited features. 
Each of these claims depends from Claim 25 and is therefore allowable for reasons 
discussed with respect to Claim 25. These claims are also allowable for their own 
recited features which, in combination with those recited in Claim 25, are not 
disclosed in the references of record. 

For the Board's convenience, the entirety of the Examiner's rejection is 
reproduced below. For expediency, Applicant presumes the Examiner is referencing 
Claim 25-28 in paragraph 25 although not specifically noted. 



"73. Claims 25-28 are rejected under 35 U.S.C. 103(a) as being unpatentable over Stevens and Peek 
(Unix Power Tools). 

74. Regarding claims 25-28, Stevens is applied as in claim 1 . Stevens fails to disclose a method for 
handling data forms. However, Peek discloses a UNIX tool that allows for handling a data form and 
receiving the information from that form. Peek, 875-879. It would be obvious to one of ordinary skill in 
the art to use the form capabilities of Peek with the teachings of Stevens to allow a user to input data 
easily. By this rationale claims 25-28 are rejected. 

Final Action, Page 17. 

25. In response to Applicant's arguments concerning the Peek reference, Peek disclosed the 
^limitations claimed by Applicant. Applicant has addressed the additional functionality of the claims but 
has not addressed it with regard to the Peek reference. 

Final Action, Page 6. 

The combination of Stevens in view of Peek fails to teach the recited 
subject matter because Peek is not cited as correct the deficiencies in Stevens with 
respect to the multiple layers and the feature of "wherein any of the layers may be 
changed without impacting other layers", as discussed above. 

Moreover, Peek fails to teach "a form processor to generate a data input 
form for the multi-layer application by automatically adding, to a form definition 
that defines the data input form, validation code to validate subsequent inputs to 
one or more fields of the data input form." (Claim 25) 

Peek is directed to filling in a form by adding a person's name, address, 
phone number, etc. Peek, Pages 875-876. The Peek reference fails to teach a 
system in which data input is generated from a multi-layer application to define 
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the data input form, or validation code to validate subsequent inputs. Peek does 
not disclose these teachings because Peek is directed to "filling in forms" rather 
than addressing defining data input forms or validating subsequent inputs. As 
Peek does not correct the deficiency in Stevens, at least with respect to defining 
data input forms and validating subsequent inputs, the asserted combination does 
not teach each and every limitation which is required for a prima facie case of 
obviousness to exist. Reversal of the pending rejection is requested. 

iv. The Examiner has failed to meet the all elements requirement embodied in 
35 U.S.C. § 103(a) and has failed to state a motivation to combine sufficient to 
meet the requirements under the law with respect to Claims 29 and 30. 

Claims 29 and 30 are pending a 35 U.S.C. § 103(a) rejection over Stevens 
in view of Tuthill. Claims 29 and 30 depend from Claiml and are allowable as 
depending from an allowable base claim, as well as for their own recited features. 
These claims are also allowable for their own recited features which, in 
combination with those recited in Claiml, are not disclosed in the references of 
record. Reversal of the pending rejection is requested. 

6. SIXTH GROUND OF REJECTION: 

The Claims 20-25 are not within the aegis of Non-Statutory Double 

Patenting (provisional). 
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i. The pending provisional non-statutory double patenting rejection of Claims 
1, 17, and 48-50 is improper as the cited claims in co-pending Application 
09/845,752 (herinafter, the '752 application) (presumed to be the basis as the 
claim language recited by the Examiner in comparison to co-pending Application 
09/847,067 do not obviate the present claims) is directed to (in part) business 
software which was the subject of a Restriction Requirement in the present 
Application. 

If, for arguments sake, we accept the Examiners argument as correct, solely 
for the purposes of this issue, the Non-Statutory Double Patenting Rejection of 
Claims 1, 17 and 48-58 is incorrect as the Examiner has issued a Restriction 
Requirement in this case (below) which notes that business orientated software is 
separately recognized in the art. Thus, the Examiner is in essence attempting to 
impose a double patenting rejection on subject matter that was generally 
recognized as separately patentable under 35 U.S.C. §121 by this Examiner. 
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Election/Restrictions 

1 . Restriction to one of the following inventions is required under 35 U.S.C. 121 : 

I. Claims 1-30 and 48-52, drawn to a multi-layer application executing on a 
computer with a problem-solving layer, classified in class 709, subclass 203. 

II. Claims 31-47, drawn to a business-oriented computer software architecture with 
a business logic module, classified in class 705, subclass 39. 

ill. Claims 52-57, drawn to a method for creating server applications for multiple 
different domains, classified in class 717, subclass 106. 
The inventions are distinct, each from, the other because of the following reasons: 

2. Inventions I, II and III are related as subcombinations disclosed as usable together in a 
single combination. The subcombinations are distinct from each other if they are shown to be 
separately usable. In the instant case, invention I has separate utility such as a multi-layer 
application executing on a computer with a problem-solving layer, but lacks a business logic 
module and creating server applications. Invention II has separate utility as a business-oriented 
computer software architecture with a business logic module, but lacks a problem-solving layer 
and creating server applications. Invention 111 has separate utility as a method for creating server • 
applications for multipie different domains, but lacks a business logic module and a multi-layer 
application. See MPEP § 806.05(d). 

3. Because these inventions are distinct for the reasons given above and have acquired a 
separate status in the art as shown by their different classification, restriction for examination 
purposes as indicated is proper. 

4. Because these inventions are distinct for the reasons given above and the search 
required for Group I is not required for Groups II and III, restriction for examination purposes as 
indicated is proper. 

5. A telephone call was made to Lewis C. Lee on December 9, 2004 to request an oral 
election to the above restriction requirement, but did not result in an election being made. 

Claim 1 of the '752 application, in part, recites "a business logic layer to 
process the client requests according to a particular business domain and produce 
replies to be returned to the clients in response to the client requests;" While 
withdrawn Claim 31 (both of these Claims are reproduced below), of the Instant 
application, in part, recites "a first business logic module to process the client 



54 



requests received by the framework according to an associated business purpose, 
the first business logic module generating replies corresponding to the client 
requests." Reversal of the pending provisional Non-Statutory Double Patenting 



Rejection with respect to Claims 1,17, and 48-50 is requested. 



Claim 1 of the '752 Application 


Withdrawn Claim 3 1 of the Instant Application 


A server system, comprising: 

one or more computers; and 

an application executing on the computers 
to handle client requests, the application 

a business logic layer to process the client 
requests according to a particular business domain 
and produce replies to be returned to the clients in 
response to the client requests; 

a presentation layer separate from, but in 
communication with, the business logic layer to 
structure the replies in a manner that makes the 
replies presentable on different types of client 
devices according to a tag library containing pre- 
constructed tags for a variety of data formats; and 
a request dispatcher to structure a reply for service 
back to a client device, the request dispatcher being 
configured to access the tag library to obtain tags to 
structure the reply according to a particular data 
format. 


A business-oriented computer software 
architecture stored on one or more computer- 
readable media, comprising: 

a framework module to receive client 
requests from different client devices; 

a first business logic module to process the 
client requests received by the framework according 
to an associated business purpose, the first business 
logic module generating replies corresponding to 
the client requests; 

a presentation module to structure the 
replies produced by the first business logic module 
in a manner that makes the replies presentable on 
the client devices; and 

the business-oriented computer software 
architecture being reconfigurable to another 
business purpose by substituting a second business 
logic module for the first business logic module. 



Similarly, the pending obviousness double patenting rejection of Claims 
20-25 is improper because, 

1. The citation of two references, i.e., A (Application 09/847,037) in 
view of B (Application 09/845,752) (in the case of Claims 23 and 24), as the basis 
of an obviousness double patenting rejection is improper based on the rationale 
cited above with respect to Claim 1. While a citation to a second reference is not 
perse improper under the M.P.E.P, the necessity of a second reference to "fill-in" 
the missing subject matter between the "reference" claims and the claims at issue 
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indicate that the subject matter is discernibly different. The further citation of a 
total of four "references", with respect to Claim 25, indicates that the same subject 
matter is not being claimed as four co-pending applications are needed to "cobble 
together" the same claimed invention. Additionally, the Examiner has failed to 
provide a motivation to combine all four of the co-pending applications such that 
the "same invention" is being claimed pursuant to establishing a Non-Statutory 
Double Patenting Rejection. 

2. The applications upon which the rejection is based were filed on the 
same day as the present application and thus are not "art", if the Office is 
attempting to reject the claims based on a 35 U.S.C. §§ 102(e) or 103(a) rationale. 
Additionally, as the applications were filed on the same date, there is very little 
risk of unjustified or improper timewise extension of the right to exclude that the 
Son-Statutory Double Patenting Doctrine was designed to address. 

3. The Examiner has not established a prima facie case of 
"obviousness" akin to that for a 35 U.S.C. § 103(a) rejection including elaborating 
a motivation to combine the reference claims with the asserted secondary 
reference. M.P.E.P. £804. As the Supreme Court recently noted, "[^ejections on 
obviousness grounds cannot be sustained by mere conclusory statements; instead, 
there must be some articulated reasoning with some rational underpinning to 
support the legal conclusion of obviousness." KSR International Co. v. Teleflex, 
550 U.S. unknown, 04-1350, 1 14 (2007). 
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4. In the current situation the Office is attempting to reject claims in the 
application over combinations of disclosures in multiple applications. This 
methodology is improper because (1) the co-pending claims are not considered, 
instead the co-pending applications is applied as a secondary reference, and (2) as 
the rejection is based on multiple applications. Reversal of the pending Non- 
Statutory Double Patenting Rejection is requested. 

Conclusion 

The Applicant respectfully considers this application to be in condition for 
allowance and respectfully requests the Board to overturn the final rejection and 
that the Examiner pass this application to allowance. 

s 

Dated this r day o f fa. , 2007 



Respectfully Submitted, 




Attorney for the Applicant 
Reg. No. 48,600 

LEE & HAYES PLLC 

421 W. Riverside Avenue, Suite 500 

Spokane WA, 99201 

Telephone: (509) 324-9256 (ext. 228) 

Fax: (509) 323-8979 
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CLAIMS APPENDIX 



1 . A server system comprising: 
one or more computers; and 

a multi-layer application executing on the computers to handle client 
requests submitted by various client devices, the multi-layer application 
comprising: 

a problem-solving logic layer to process the client requests according to an 
associated problem domain, wherein the problem domain pertains to a particular 
category of service, the problem-solving logic layer containing one or more 
execution models to perform various sets of tasks when processing the client 
requests, the problem-solving logic layer producing replies to the client requests; 

an execution environment layer to receive the client requests and select an 
appropriate execution model in the problem-solving logic layer for processing the 
client requests; 

an interfacing layer to interface the problem-solving logic layer with one or 
more resources so that the execution models may utilize the resources when 
processing the client requests; and 

a presentation layer to receive the replies produced by the problem- solving 
logic layer and to structure the replies in a manner that makes the replies 
presentable on the various client devices, 

wherein any of the layers maybe changed without impacting other layers. 

2. A server system as recited in claim 1, wherein the execution environment 
layer comprises a framework to receive the client requests and route the requests 
to the problem-solving logic for processing. 
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3. A server system as recited in claim 2, wherein the execution environment 
layer comprises one or more adapters to interface the framework with different 
types of the client devices. 

4. A server system as recited in claim 1, wherein the execution environment 
layer comprises: 

a model dispatcher to route the client requests to selected execution models 
in the problem- solving logic layer; and 

a request dispatcher to structure the replies for return to the client devices. 

5. A server system as recited in claim 1, wherein the multi-layer application 
can be adapted to receive requests from new client devices with incompatible 
communication protocols by substituting a new execution environment layer that 
supports the new client devices. 

6. A server system as recited in claim 1, wherein one of the execution 
models is embodied as a set of discrete program modules, each program module 
performing a specific task. 

7. A server system as recited in claim 1, wherein one of the execution 
models is embodied as an interaction-based model in which computer programs 
are defined by a series of interaction definitions. 
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8. A server system as recited in claim 1, wherein the execution models are 
embodied according to at least one of a command model, an action- view model, 
and a use case model. 

9. A server system as recited in claim 1, wherein one of the execution 
models performs tasks according to a first business purpose, and the multi-layer 
application being reconfigurable to achieve a different business purpose by 
installing another execution model that performs tasks according to the second 
business purpose. 

10. A server system as recited in claim 1, wherein the interfacing layer 
comprises: 

a data abstraction layer to obtain data from the resources and map the data 
into a domain framework that models information flow for a specific problem 
domain; and 

a data coordination layer that provides an interface for the problem-solving 
logic layer to access the domain framework of the data abstraction layer and 
obtain the data. 

1 1. A server system as recited in claim 10, wherein the data coordination 
layer comprises one or more application data managers that interface the domain 
framework in the data abstraction layer into an application solution space of the 
problem-solving logic layer. 
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12. A server system as recited in claim 1, wherein the multi-layer 
application can be adapted to access new resources by substituting in a new 
interfacing layer that supports the new resources. 

13. A server system as recited in claim 1, wherein the client devices support 
different data formats, the presentation layer being configured to select appropriate 
data formats for encoding the replies. 

14. A server system as recited in claim 1 , wherein the client devices support 
different communication protocols, the presentation layer being configured to 
select appropriate communication protocols for delivering the replies to the 
clients. 

15. A server system as recited in claim 1, wherein the presentation layer is 
configured to determine how to display the replies for a particular client. 

16. A server system as recited in claim 1, wherein the presentation layer is 
configured to determine at least one of (1) a layout of individual replies, (2) 
display attributes in which to present the replies, and (3) a presentation theme. 

17. A server system as recited in claim 1, wherein the presentation layer 
comprises: 

a presentation module to determine how the replies will appear on the client 
devices to users; and 
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a rendering module, separate from the presentation module, to determine 
how to render the replies on the client devices. 

18. A server system as recited in claim 1, further comprising an 
authentication module to authenticate the client devices or users of the client 
devices. 

19. A server system as recited in claim 1, further comprising a constraint 
system to constrain operation of the multi-layer application according to a 
hierarchy of different constraints. 

20. A server system as recited in claim 1, further comprising a constraint 
system to constrain operation of the multi-layer application according to multiple 
different constraints, the constraint system comprising a hierarchy of constraint 
layers, with each constraint layer containing a set of one or more constraints that 
customize operation of the multi-layer application. 

21. A server system as recited in claim 1, further comprising: 

a constraint hierarchy of multiple constraint layers, each constraint layer 
containing a set of one or more constraints that constrain operation of the multi- 
layer application, the constraint layers being organized within the constraint 
hierarchy such that a first constraint layer limits a second constraint layer but the 
second constraint layer does not limit the first constraint layer; and 
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a constraint resolver to resolve the constraint layers so that operation of the 
multi-layer application is constrained by a set of the constraints in the constraint 
layers. 

22. A server system as recited in claim 21, wherein the hierarchy of 
constraints comprises constraints selected from a group of constraints comprising: 

legally mandated constraints to constrain operation of the multi-layer 
application according to legal principles; 

company-mandated constraints to constrain operation of the multi-layer 
application according to preferences of a company that operates the application; 

customer constraints to constrain operation of the multi-layer application 
according to preferences of customers; 

cultural constraints to constrain operation of the multi-layer application 
according to cultural aspects; and 

end user constraints to constrain operation of the multi-layer application 
according to preferences of an end user. 

23. A server system as recited in claim 1, further comprising a security 
policy enforcement module to enforce security restrictions on accessing 
information stored at the one or more resources. 

24. A server system as recited in claim 23, wherein the security policy 
enforcement module is to enforce the security restrictions based on a set of low- 
level security rules defined using high-level permission concepts. 
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25. A server system as recited in claim 1, wherein the presentation layer 
includes a form processor to generate a data input form for the multi-layer 
application by automatically adding, to a form definition that defines the data 
input form, validation code to validate subsequent inputs to one or more fields of 
the data input form. 

26. A server system as recited in claim 25, wherein the form processor is to 
generate the data input form by identifying one or more custom tags associated 
with the data input form, to replace each of the one or more custom tags with 
another tag, and further to add to the form definition, for each of the one or more 
replaced tags, validation code to validate subsequent inputs to a field 
corresponding to the tag. 

27. A server system as recited in claim 25, wherein the form processor is 
further to automatically identify one or more data input fields to be included in the 
form definition. 

28. A server system as recited in claim 25, wherein the form processor is 
further to automatically identify one or more restrictions associated with a data 
input field of the data input form, and to determine the validation code based at 
least in part on the one or more restrictions. 

29. A server system as recited in claim 1, further comprising: 

a resource bundle containing locale-specific content that is authored for a 
particular locale; and 
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a resource bundle manager to populate a locale-independent core with the 
locale-sensitive content in the resource bundle to produce a computer-servable 
document that can be served by the multi-layer application to the particular locale. 

30. A server system as recited in claim 29, wherein the resource bundle 
manager resides in the interfacing layer. 

Claims 31-47 are withdrawn. 

48. A method for processing client requests in a system, comprising: 

receiving requests from multiple clients, the requests being related to a 
business-related problem domain, wherein the business-related problem domain 
pertains to a particular category of business-related service; 

processing the requests within problem-solving logic to produce replies 
within the business-related problem domain, the processing comprising requesting 
data to be used in formulating the replies; 

retrieving the data from one or more external resources and mapping the 
data to a domain framework for the business-related problem domain, the domain 
framework being independent from the problem-solving logic; and 

interfacing the problem-solving logic to the domain framework to obtain 
the data for use in processing the request, 

wherein a new business-related problem domain can be exchanged for a 
previous business-related problem domain by replacing one or more components 
of the system, without having to reconstruct an entire application solution for the 
new business-related problem domain. 
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49. A method as recited in claim 48, further comprising structuring the 
replies for presentation to the clients. 

50. A method as recited in claim 48, further comprising: 

structuring the replies to define how the replies will appear when presented 
at the clients; and 

independent of said structuring, conforming the replies to output 
capabilities of the clients. 

5 1 . A method as recited in claim 48, further comprising constraining how 
the replies are presented according to a hierarchy of constraints, wherein the 
hierarchy of constraints comprises multiple constraints such that a first constraint 
limits a second constraint but the second constraint does not limit the first 
constraint. 

Claims 52-57 are withdrawn. 

58. A server system comprising: 
one or more computers; and 

a multi-layer application executing on the computers to handle client 
requests submitted by various client devices, the multi-layer application 
comprising: 

a problem-solving logic layer to process the client requests according to an 
associated problem domain, wherein the problem domain pertains to a particular 
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category of service, the problem-solving logic layer containing one or more 
execution models to perform various sets of tasks when processing the client 
requests, the problem-solving logic layer producing replies to the client requests; 

an execution environment layer to receive the client requests and select an 
appropriate execution model in the problem-solving logic layer for processing the 
client requests; 

an interfacing layer to interface the problem-solving logic layer with one or 
more resources so that the execution models may utilize the resources when 
processing the client requests, 

wherein the interfacing layer comprises: 

a data abstraction layer to obtain data from the resources and 
map the data into a domain framework that models information flow 
for a specific problem domain; and 

a data coordination layer that provides an interface for the 
problem-solving logic layer to access the domain framework of the 
data abstraction layer and obtain the data; and 
a presentation layer to receive the replies produced by the problem-solving 
logic layer and to structure the replies in a manner that makes the replies 
presentable on the various client devices. 
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EVIDENCE APPENDIX 



RELATED PROCEEDINGS APPENDIX 

None. 
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Appendix A: Version of Exemplary and Non-Limiting Support for 
Claims in Specification provided 4/28/06 



_Cl f um 


( laim Mement 


Exemplary and Non-Limiting Support 
in Text 


Exemplary and Non-Limiting 
Support in Drawings 




A server system comprising: 

one or more computers; and 

a multi -layer application executing on 

the computers to handle client requests 

submitted by various client devices, the 

multi-layer application comprising: 


at least page 6, line 24 to page 8, linel 8 


at least multi-layer architecture 
110 implemented on one or more 
computers 112 that interact with 
various client devices 102 




a problem-solving logic layer to process 
the client requests according to an 
associated problem domain, wherein the 
problem domain pertains to a particular 
category of service, 


at least pagelO, line 25 to page 11, line 
28; page 19, line 4 to page 33, line 1 


at least business logic layer 204 




the problem-solving logic layer 
containing one or more execution models 
to perform various sets ot tasks when 
processing the client requests, the 
problem-solvmg logic laver producing 
replies to the client requests; 


at least page 1.1, lines 5-28; page 19, line 
4 to page 33, line I 


at 1 .in il j .i ii i. i 

models 230; Figs. 4-6 shows one 
example of an execution model 
for an asset catalogue application 




an execution environment layer to 
receive the client requests and select an 
appropriate execution model m the 
problem-solving logic layer for 
processing the client requests: 


at least page 9, line22 to page 1 0, line 24 






an interfacing laver to interface the 
problem-solving logic layer with one or 
more resources so that the execution 
models may utilize the resources when 
processing the client requests; 


at least page 12, line 1 to page 13, line 24 


note the various layers in Fig. 2 
that serve at interfacing role, such 
as the data coordination layer 206 
and the data abstraction layer 208 




and a presentation layer to receive the 
replies produced by the problem-solving 
logic layer and to structure the replies in 
a manner that makes the replies 
presentable on the various client devices, 


at least page 13, line 25 to page 15, line 
17; page 45, line 21 to page 50, line 16 


at least presentation layer 212; 
Figs. 10 and 11 




wherein any of the layers may be 
changed without impacting other layers. 


at least page 4, lines 6-10"; page 6, lines 
11-14; page 9, lines 11-21 


note generally the layers of Fig. 2 




A server system as recited in claim 1, 
wherein the execution environment layer 
comprises a framework to receive the 
client requests and route the requests to 
the problem-solving logic tor processing. 


at least page 1 0, lines 1-17 


at least framework 220 


3 


A server system as recited m claim 2, 
wherein the execution environment layer 
comprises one or more adapters to 
interface the framework with different 
types of the client devices. 


at least page 10, lines 18-24 


at least adapters 228 


4 


A server system as recited m claim 1, 
wherein the execution environment layer 
comprises: 

a model dispatcher to route the client 
requests to selected execution models in 
the problem-solving logic layer; and 


at least page 10, lines 6-17 


at least model dispatcher 222 




a request dispatcher to structure the 
replies for return to the client devices. 


at least page 10, lines 6-17 


at least request dispatcher 224 


5 


A server system as recited in claim 1, 
wherein the multi-layer application can 
be adapted to receive requests from new 


at least page 4, lines 6-10; page 6, lines 
11-14; page 9, lines 11-21 


note generally the layers of Fig. 2, 
and particularly the role of the 
execution environment layer 202 | 
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Claim 


Claim Element 


Exemplary and Non-Limiting Support 
in Text 


Exemplary and Non-Limiting 
Support in Drawings 




client devices with incompatible 
communication protocols by substituting 
a new execution environment layer that 
supports the new client devices. 






6 


A server system as recited m claim 1, 
wherein one of the execution models is 
embodied as a set of discrete program 
modules, each program module 
performing a specific task. 


at least page 11, lines 5-28; page 19, line 
4 to page 33, line 1 


models 230; Figs. 4-6 shows one 
example of an execution model 
for an asset catalogue application 


7 


A server system as recited m claim I, 
wherein one ol the execution models is 
embodied as an interaction-based model 
m which computer programs are defined 
bv a series of interaction definitions. 


at least page 1 1, lines 5-28; page 19, line 
4 to page 33, line 1 


models 230; Figs. 4-6 shows one 
example of an execution model 
for an asset catalogue application 


X 


A server system as recited m claim 1. 
wherein the execution models are 
embodied according to at least one of a 
command model, an action-view model, 
and a use case model. 


at least page 11, lines 5-28; page 19, line 
4 to page 33, line 1 


models 230; Figs. 4-6 shows one 
example of an execution model 


9 


A server system as recited m claim 1. 
wherein one ol the execution models 
performs tasks according to a first 
business purpose, and the multi-layer 
application being reconfigurable to 
achieve a different business purpose by 
installing another execution model that 
performs tasks according to the second 
business purpose. 


at least page 11, lines 5-28; page 19, line 
4 to page 33, line 1; also note at least 
page 4. lines 6-10; page 6, lines 11-14; 
page 9. lines 11-21 


models 230; Figs. 4-6 shows one 
example of an execution model 
for an asset catalogue application 


10 


A server system as recited in claim 1, 
wherein the interfacing layer comprises: 
a data abstraction laver to obtain data 
from the resources and map the data into 
a domain framework that models 
information flow for a specific problem 
domain; and 


at least page 1 2, line 1 to page 1 3, line 24 


note at least data abstraction layer 
208 


a data coordination layer that provides an 
interface for the problem-solving logic 
layer to access the domain framework of 
the data abstraction layer and obtain the 


at least page 12, line f to page t3, line 24 


note at least data coordination 
layer 206 


» 


wherem the data coordination layer 
comprises one or more application data 
managers that interface the domain 
framework in the data abstraction layer 
into an application solution space of the 
problem-solving logic layer. 


at least page 1 2, line 1 to page 13, line 24 


note data coordination layer 206, 
and particularly the role ot 
application data managers 240 


u 


A server system as recited in claim 1, 
wherein the multi-layer application can 
be adapted to access new resources by 
substituting in a new interfacing layer 
that supports the new resources. 


at least page 4, lines 6-10; page 6, lines 
11 -14; page 9, lines 11-21 ' 


note generally the layers of Fig. 2, 
and particularly the data 
coordination layer 206 and the 
data abstraction layer 208 which 
interact with the resources 108 


13 


A server system as recited in claim 1, 
wherem the client devices support 
different data formats, the presentation 
layer being configured to select 
appropriate data formats for encoding the 


at least page 13, line 25 to page f5, line 
1 7; page 45, line 21 to page 50, line lb 


at least presentation layer 212; 
Figs. 10 and 11 




A server system as recited in claim 1, 
wherem the client devices support 
different communication protocols, the 
presentation layer being configured to 
select appropriate communication 
protocols for delivering the replies to the 
clients. 


at least page 13, line 25 to page 15, line 
1 7; page 45, line 2 1 to page 50, line 1 6 


at least presentation layer 212; 
Figs. 10 and 11 


15 


A server system as recited in claim 1, 
wherein the presentation layer is 


at least page 13, line 25 to page 15, line 
17; page 45, line 21 to page 50, line 16 


at least presentation layer 212; 
Figs. 10 and 11 
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Claim 


Claim Element 


Exemplary and Non-Limiting Support 
in Text 


Exemplary and Non-Limiting 
Support in Drawings 




configured to determine how to display 
the replies for a particular client. 






16 


A server system as recited in claim 1, 
wherein the presentation layer is 
configured to determine at least one of 
(.1) a layout of individual replies, (2) 
display attributes m which to present the 
replies, and (3) a presentation theme. 


at least page 13, line 25 to page 15, line 
17; page 45, line 21 to page 50, line 16 


at least presentation layer 212; 
Figs. 10 and 1 1 


17 


A server system as recited m claim 1, 
wherein the presentation layer 
comprises: 

a presentation module to determine how 
the replies will appear on the client 
devices to users; and 


at least page 13, line 25 to page 15, line 
17; page 45, line 21 to page 50, line 16 


at least presentation layer 212; 
Figs. 10 and 11; note particularly 
presentation functionality 224 




a rendering module, separate from the 
presentation module, to determine how 
to render the replies on the client 
devices. 


at least page 13, line 25 to page 15, line 
17; page 45, line 21 to page 50, line 16 


at least presentation layer 212; 
Figs. 10 and 11; note particularly 
content renderer 260 




A server system as recited m claim 1. 
further comprising an authentication 
module to authenticate the client devices 
or users of the client devices. 




authentication module 270 


19 


A server system as recited in claim 1. 
further comprising a constraint system to 
constrain operation of the multi-layer 
application according to a hierarchy of 
different constraints. 


at least page 50, line 17 to page 55, line 


at least Figs. 12 and 13 


20 


A server system as recited in claim 1, 
further comprising a constraint system to 
constrain operation of the multi-layer 
application according to multiple 
different constraints, the constraint 
system comprising a hierarchy of 
constraint layers, with each constraint 
layer containing a set ol one or more 
constraints that customize operation of 
the multi-layer application. 


at least page 50, line 17 to page 55, line 
25 


at least Figs. 12 and 13 


21 


A server system as recited m claim 1, 
further comprising: 

a constraint hieraTchv of multiple 
constraint layers, each constraint layer 
containing a set of one or more 
constraints that constrain operation of the 
multi-layer application, the constraint 
layers being organized within the 
constraint hierarchy such that a first 

layer but the second constraint layer does 
not limit the first constraint layer; and 


at least page 50, line 17 to page 55, line 
25 


at least Figs. 12 and 13; note 
particular hierarchy of constraints 
1202 




a constraint resolver to resolve the 
constraint layers so that operation of the 
multi-layer application is constrained by 
a set of the constraints in the constraint 


at least page 50, line 17 to page 55, line 
25 


at least Figs. 12 and 13; note 
particularly constraint resolver 
1204 
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Claim 


Chuin Lltmcnt 


Exemplary and Non-Limiting Support 
in Text 


Exemplary and Non-Limiting 
Support in Drawings 


22 


A server system as recited in claim 21. 
wherem the hierarchy of constraints 
comprises constraints selected from a 
group of constraints comprising: 
legally mandated constraints to constrain 
operation ot the multi-layer application 
according to legal principles: 
company-mandated constraints to 
constrain operation ot the multi-layer 
application according to preferences ot a 
company that operates the application; 

operation of the multi-layer application 

cultural constraints to constrain operation 
ot the multi-layer application according 
to cultural aspects: 

operation ot the multi-laver application 
according to preterences ot an end user. 


at least page 50, line 17 to page 55, line 
25 




23 


A server system as recited in claim 1, 
lurther comprising a security policy 
enlorcement module to entorce security 

stored at the one or more resources. 


at least page 15, lines 18-26; page 33, 
hne2 to page 45, line 20 


at least security policy 
enforcement module 280; Fias. 7- 
9 


24 


A server system as recited in claim 23, 
wherem the security policy enforcement 
module is to enforce the security 
restrictions based on a set ot low-level 
security rules defined using high-level 
permission concepts. 


at least page 15, lines 18-26; page 33, 
line2 to page 45, line 20 


at least security policy 
enforcement module 280; Fies. 7- 
9; note particularly Fig. 8 




A server system as recited in claim 1, 

form processor to generate a data input 
lorm for the multi-layer application by 
automatically adding, to a form 
definition that detines the data input 
form, validation code to validate 
subsequent inputs to one or more fields 
ot the data input fonn. 


at least page 56, line 1 to page 91, line 28 


at least Figs. 14-19 


26 


A server system as recited m claim 25, 
wherem the form processor is to generate 
the data input form by identifying one or 

data input form, to replace each of the 
one or more custom tags with another 
tag, and turther to add to the form 
definition, for each ot the one or more 

subsequent inputs to a field 
corresponding to the tag. 


at least page 56, line 1 to page 9t, line 28 


at least Figs. 14-19 


27 


A server system as recited m claim 25. 
wherein the form processor is turther to 
automatically identify one or more data 
input fields to be included in the form 
definition. 


at least page 56, line 1 to page 91, line 28 


at least Figs. 14-19 


28 


A aerver system as recited m claim 25. 
wherein the form processor is further to 
automatically identity one or more 
restrictions associated with a data input 
field of the data input form, and to 
determine the validation code based at 
least in part on the one or more 


at least page 56, line 1 to page 91, line 28 


at least Figs. 14-19 


29 


A server system as recited m claim 1, 
further compnsing: 


at least page 92, line 1 to page 101, line 
15 


at least Figs. 20-23 
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Claim 


Claim Element 


Exemplary and Non-Limiting Support 
in Text 


Exemplary and Non-Limiting 1 
Support in Drawings | 




a resource bundle containing locale- 
specific content that is authored for a 
particular locale; 








a resource bundle manager to populate a 
locale-independent core with the locale- 
sensitive content in the resource bundle 
to produce a computer-servable 
document that can be served by the 
multi-layer application to the particular 
locale. 


at least page 92, line 1 to page 101, line 
If 


at least Figs. 20-23 


31) 


A server system as recited in claim 29, 
wherein the resource bundle manager 
resides in the interfacing layer. 


at least page 92, line 1 to page 101, line 
15 


at least Figs. 20-23 




A method for processing client requests 
in a system, comprising: 
receiving requests trom multiple clients, 
the requests being related to a business- 
related problem domain, wherein the 
business-related problem domain 
pertains to a particular category ot 
business-related service: 


at least page 16, lines 2-24 


at least operation 302; clients 102; 
business logic layer 204 




processing the requests within problem- 
solving logic to produce replies within 
the business-related problem domain, the 
processing comprising requesting data to 
be used m formulating the replies, 
retrieving the data from one or more 
external resources and mapping the data 
to a domain framework for the business- 
related problem domain, the domain 
framework being independent from the 
problem-solving logic; 

interlacing the problem-solving logic to 
the domain framework to obtain the data 
for use m processing the request, 


at least page 17, line 23 to page 18, line 
21; also note page at least page 12, line 1 
to page 13, line 24 


at least operations 308-314; 
resources 108; domain framework 
250 




wherein a new business-related problem 
domam can be exchanged for a previous 
business-related problem domain by 
replacing one or more components of the 
system, without having to reconstruct an 
entire application solution for the new 
business-related problem domain. 


at least page 4, lines 6-10; page 6, lines 
11-14; page 9, lines 11-21 


at least note generally the layers of 
Fig. 2 


49 


A method as recited in claim 48, further 
comprising structuring the replies for 
presentation to the clients. 


at least page 18, line 16 to page 19, line 
2; page 13, line 25 to page 15, line 17; 
;page 45, line 21 to page 50, line 16 


at least operations 316-320; 
presentation layer 212: Figs. 10 


50 


A method as recited in claim 48, further 
comprising: 

structuring the replies to define how the 
replies will appear when presented at the 
clients; and 

independent of said structuring, 
conforming the replies to output 
capabilities of the clients. 


at least page 18, line 16 to page 19, line 
2; page 13, line 25 to page 15, line 17; 
;page 45, line 21 to page 50, line 16 


at least operations 316-320; 
presentation layer 212; Figs. 10 
and 11 


51 


A method as recited in claim 48, further 
comprising constraining how the replies 
are presented according to a hierarchy of 

constraints comprises multiple 
constraints such that a first constraint 
limits a second constraint but the second 
constraint does not limit the first 


at least page 50, line 17 to page 55, line 
25 


at least Figs. 12 and 13 


58 


58, (New) A server system comprising: 
one or more computers; and | 


at least page 6, line 24 to page 8, linel 8 


at least multi-layer architecture 
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Claim Element 


Exemplary and Non-Limiting Support 
in Text 


Exemplary and Non-Limiting 
Support in Drawings 




a multi-layer application executing on 
the computers to handle client requests 
submitted by various client devices, the 
multi-layer application comprising: 




computers 112 that interact with 
various client devices 102 


a problem-solving logic layer to process 
the client requests according to an 
associated problem domain, wherein the 
problem domain pertains to a particular 
category of service, the problem-solving 
logic layer containing one or more 
execution models to perform various sets 

requests, the problem-solving logic layer 
producing replies to the client requests;. 


at least pagelO, line 25 to page 11, line 
28; page 19, line 4 to page 33, line 1 


at least business logic layer 204: 
one or more execution models 
230; Fias. 4-6 shows one example 
of an execution model for an asset 
catalogue application 


an execution environment layer to 
receive the client requests and select an 
appropriate execution model in the 
problem-solvmg logic layer lor 
processing the client requests; 


at least page 9, line22 to page 10, line 24 


execution environment zQi 


an interfacing layer to interface the 
problem-solving logic layer with one or 
more resources so that the execution 
models may utilize the resources when 
processing the client requests, 
wherein the interfacing layer comprises: 
a data abstraction layer to obtain data 
from the resources and map the data into 
a domain framework that models 
information flow for a specific problem 
domain; and 

a data coordination layer that provides an 
interface for the problem-solving logic 
layer to access the domain framework of 
the data abstraction layer and obtain the 
data; and 


at least page 12, line 1 to page 13, line 24 


note the various layers in Fig. 2 
that serve at interfacing role, 
including the data coordination 
layer 206 and the data abstraction 
layer 20S 


a presentation layer to receive the replies 
produced by the problem-solving logic 
layer and to structure the replies m a 
manner that makes the replies 
presentable on the various client devices 


at least page 13, line 25 to page 15, line 
17; page 45, line 21 to page 50, line 16 


at least presentation layer 212; 
Figs. 10 and 11 
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